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1 Introduction 


This specification is part of the NFC Forum documentation about tag types that NFC Forum 
Devices need to support in NFC Forum Reader/Writer Mode. 


This specification documents how an NFC Forum Device SHALL operate an NFC Forum Type 3 
Tag. This is not a specification of the NFC Forum Type 3 Tag itself. 


1.1 Objectives 


The purpose of this specification is to document the requirements and to specify, with a set of 
rules and guidelines, the NFC Forum Device operation and management of a Type 3 Tag. 


This specification also defines data mapping and how the NFC Forum Device detects, reads, and 
writes NDEF data into the Type 3 Tag Platform in order to achieve and maintain 
interchangeability and interoperability. 


1.2 Applicable Documents or References 


[ANALOG] NFC Analog, 
In progress, 
NFC Forum 


[DIGITAL] NFC Digital Protocol, 
Version 1.0, 
NFC Forum 


[NDEF] NFC Data Exchange Format, 
Version 1.0, 
NFC Forum 


[RFC2119] Key words for use in RFCs to Indicate Requirement Levels, RFC 
2119, 
S. Bradner, 
March 1997, 
Internet Engineering Task Force 


1.3 Administration 


The NFC Forum Type 3 Tag Operation Specification is an open specification supported by the 
Near Field Communication Forum, Inc., located at: 


401 Edgewater Place, Suite 600 
Wakefield, MA, 01880 


Tel.: +1 781-876-8955 
Fax: +1 781-610-9864 


http://www.nfc-forum.org/ 


The NFC Devices Technical Working Group maintains this specification. Comments, errors, and 
other feedback can be submitted at http://www.nfc- 
forum.org/apps/group_public/document.php?document_id=9800&wg_abbrev=chairs. 
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1.4 Name and Logo Usage 


The Near Field Communication Forum’s policy regarding the use of the trademarks NFC Forum 
and the NFC Forum logo is as follows: 


e Any company MAY claim compatibility with NFC Forum specifications, whether a member 
of the NFC Forum or not. 


e Permission to use the NFC Forum logos is automatically granted to designated members only 
as stipulated on the most recent Membership Privileges document, during the period of time 
for which their membership dues are paid. 


e Member’s distributors and sales representatives MAY use the NFC Forum logo in promoting 
member’s products sold under the name of the member. 


e The logo SHALL be printed in black or in color as illustrated on the Logo Page that is 
available from the NFC Forum at the address above. The aspect ratio of the logo SHALL be 
maintained, but the size MAY be varied. Nothing MAY be added to or deleted from the 
logos. 


e Since the NFC Forum name is a trademark of the Near Field Communication Forum, the 
following statement SHALL be included in all published literature and advertising material in 
which the name or logo appears: 


NFC Forum and the NFC Forum logo are trademarks of the Near Field Communication 
Forum. 


1.5 Intellectual Property 


The Type 3 Tag Operation Specification conforms to the Intellectual Property guidelines 
specified in the NFC Forum's Intellectual Property Rights Policy, as outlined in the NFC Forum 
Rules of Procedure. These documents are available on the NFC Forum website. 


1.6 Special Word Usage 


The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, 
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL.” in this 
document are to be interpreted as described in [RFC2119]. 


1.7 Convention and Notations 


1.7.1 Representation of Numbers 
The following conventions and notations apply in this document unless otherwise stated. 


e Binary numbers are represented by strings of digits 0 and 1 shown with the most significant 
bit (msb) left and the least significant bit (lsb) right, “b” is added at the end. 


Example: 11110101b 


e Hexadecimal numbers are represented using the numbers 0 - 9 and the characters A — F, an 
“h” is added at the end. The most significant byte (MSB) is shown on the left, the least 
significant byte (LSB) on the right. 


Example: F5h 
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e Decimal numbers are represented as is (without any tailing character). 


Example: 245 


1.8 Abbreviations 


The abbreviations as used in this document are defined in Table 1. 


Table 1: Abbreviations 


Abbreviation Description 

Isb least significant bit 

LSB Least Significant Byte 

msb most significant bit 

MSB Most Significant Byte 
NDEF NFC Data Exchange Format 


1.9 Glossary 
Access Attribute 

The lowest 6 bits of Service Code. This value determines how to access Block Data. 
Access Mode 


A value specified in the Block List Element that identifies the method of access to use 
when accessing Block Data. 


Block 
The smallest data unit written to or read from memory. 
Block Data 
e Data to be written to or read from a Block. 
e Data to be stored to a Block. 
Block List 
The enumeration (i.e., the ordered array) of all Block List Element instances. 
Block List Element 


Indicates the block number, the position of the Service within the Service Code List, and 
the access mode for one block. 


Block Number 


Indicates the logical position of a data block belonging to a specific Service. The NFC 
Forum Device uses this number to access the memory data. 


Command 


An instruction from one device to another device in order to move the other device 
through a state machine. 
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IDm 
Manufacture ID. The Reader/Writer uses this 8 byte number to identify each Type 3 Tag 
with which to communicate. 
Ln 
Length of the NDEF data in bytes. 
Nbc 
Number of Blocks used by the NDEF data stored on the Type 3 Tag. 
Nbr 
Number of Blocks that can be read by the Check Command at one time. 
Nbw 


Number of Blocks that can be written by the Update Command at one time. 


NFC Forum Device 


NFC-Forum-compliant device. For this document, the NFC Forum Device is always 
acting in Reader/Writer mode, which is similar to a Proximity Coupling Device (PCD) in 
ISO terminology. 


Nmaxb 

Maximum number of Blocks available for NDEF data on a Type 3 Tag. 
Overlap Service 

A Service that shares the same Block Data with another service. 
PMm 

Manufacturer Parameter that is pre-configured by the Type 3 Tag manufacturer. 
Reader/Writer 


Role of an NFC Forum Device reached when an NFC Forum Device in Poll Mode has 
gone through a number of Activities. In this mode, the NFC Forum Device behaves like a 
legacy contactless reader and uses Commands from one of the Technology Subsets. 


Response 


Information sent from one device to another device upon receipt of a Command. The 
information received by the other device should allow this other device to continue the 
data exchange. 


RWflag 
Shows whether the Type 3 Tag is “read only” or allows “read/write” access. 
Service 


The concept that identifies both the method of access to the Block Data and a set of 
Block Data. A Type 3 Tag can contain more than one Service. 


Service Code 


The value that uniquely identifies each Service. 
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Service Code List 
List of Service Codes that indicate which Services can be accessed. 
Service Code List Order 


The Service Code List Order is a field in each Block List Element. It identifies the 
Service Code that the Block belongs to. The value is the index of this Service Code in the 
Service Code List. 


Status Flag 


The information that indicates the error status of a Type 3 Tag, consisting of Status Flag1 
and Status Flag2. 


Technology 


A group of transmission Parameters defined by the NFC standard that makes a complete 
communication protocol. A non-exhaustive list of transmission Parameters is: RF carrier, 
communication mode, bit rate, modulation scheme, bit-level coding, frame format, 
protocol, and Command set. NFC defines three groups and therefore three Technologies: 
NFC-A, NFC-B, and NFC-F. The three Technologies use the same RF carrier (13.56 
MHz). Each Technology uses its own modulation scheme, bit-level coding, and frame 
format, but may have the same protocol and Command set. 


Technology Subset 


A legacy platform supporting a subset of a Technology. A Technology Subset supports at 
least the Poll Command of the Technology. The four Technology Subsets described in 
this specification are: 


e Type 1 Tag Platform, which uses a particular subset of NFC-A, excluding anti- 
collision. 


e Type 2 Tag Platform, which uses a particular subset of NFC-A, including anti- 
collision. 


e Type 3 Tag Platform, which uses a particular subset of NFC-F. 


e Type 4 Tag Platform, which uses a particular subset of NFC-A or NFC-B, including 
anti-collision. 


Type 3 Tag 


NFC Forum Type 3 compatible Tag, card, or token, including a contactless IC chip, 
which has built-in memory and memory access functions. The physical shape is not 
defined. 


WriteFlag 


Flag that indicates the current process of writing (ongoing or not). 
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2 Memory Structure and Management 


2.1 Blocks 


The basic unit of information used in memory management is called a block. Each block has a 
fixed size of 16 bytes. The number of memory blocks available depends on the chip hardware. 
Memory blocks are not addressed directly but relative to the Service they belong to. 


2.2 Services 


Services are similar to files in a file system. Each Service has a number of memory blocks 
associated with it. Services can be addressed using their Service Code, which must be unique 
inside each Type 3 Tag. 


2.3 System Information 


Each Type 3 Tag contains management data, called “System Information”. The System 
Information of a Type 3 Tag consists of the following parts: 


e Manufacture Information 

e System Definition Information 

e Service Definition Information 

Manufacture ID Information and System Definition Information are pre-assigned by the Type 3 
Tag manufacturer. 

2.3.1 Manufacture Information 


Manufacture Information consists of the Manufacture ID (IDm) and the Manufacture Parameter 
(PMm). The Manufacture Information cannot be deleted or rewritten by users. 


Manufacture Information (16 bytes) 


£ IDm PMm ; 
( Y \ 


DO|D1}D2|D3)D4|D5|D6|D7|D8|D9|Da|Db|Dc|Dd|De} Df 


Maximum 
Update 


Response 
Check | Time Parameter 


Figure 1: Manufacture Information 


2.3.1.1 Manufacture ID (IDm) 


The Manufacture ID (IDm) is an 8 byte number that is used by the NFC Forum Device to address 
a Type 3 Tag. 


The IDm is defined in [DIGITAL] under the name of NFCID2. 
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2.3.1.2 Manufacture Parameter (PMm) 

The Manufacture Parameter (PMm) contains the Maximum Response Time parameters. 

The PMm consists of the following fields defined in [DIGITAL] as part of SENSF_RES: PADO, 
PAD1, MRTIcHecx, MRTIuppate, and PAD2. 

2.3.2 System Definition Information 

The System Definition Information consists of the System Code. 


The System Code is a 2 byte number. The NFC Forum Device can use the corresponding 
parameter in the Polling Command to poll targets that have a specific System Code. 


The System Code is coded in Big Endian order. 


2.3.3 Service Definition Information 


A Service Definition Information is present for each Service that exists on a Type 3 Tag. It 
consists of the Service Code and the Number of Blocks for the Service. 


The Service Code uniquely identifies the Service on a Type 3 Tag. It has a length of 2 bytes. The 
format is Little Endian. 


The Service Code consists of a Service Number and an Access Attribute. The Service Number 
has a length of 10 bits (the 10 most significant bits of the 2 bytes) and is unique for each Service 
of a Type 3 Tag. The Access Attribute has a length of 6 bits (the 6 least significant bits of the 
Service Code) and specifies the permissions for accessing the associated memory blocks. 


[RQ_T3T_MEM_001] The Access Attribute SHALL be interpreted by the NFC Forum Device 
as described in Table 2: 


Table 2: Access Attributes 
Access 
001001b | Read/Write Data can be read or written. 


Only reading data is 
possible. 


001011b | Read only 


The Number of Blocks is a 2 byte number specifying the number of memory blocks associated 
with this Service. 


Each Service Definition Information usually references a number of memory blocks that are 
exclusively used by this Service. The only exceptions are Overlap Services, which share the same 
memory blocks but have different Access Attributes (e.g., read only or read/write). 
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3 Analog Interface 
The RF interface of the NFC Forum Device is defined in [ANALOG]. 


[RQ_T3T_RFI_001] The NFC Forum Device SHALL comply with the analog interface as 
defined in [ANALOG] for NFC-F. 
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4 Framing and Transmission Handling 


4.1 Frame Structure 


[RQ_T3T_FTH_001] The NFC Forum Device SHALL comply with the Sequence Format, the 
Bit Level Coding, Frame Format, and Data and Payload Format defined in [DIGITAL] for Type 3 
Tag Platform. 


4.2 Communication Protocol 


[RO T3T. FTH. 002] The communication protocol SHALL comply with the requirements 
given in [DIGITAL] Section 7 for half-duplex communication protocols and the definitions given 
in [DIGITAL] for the Type 3 Tag Platform. 


4.3 Communication Endpoints 


The NFC Forum Device and the Type 3 Tag are always the endpoints of the communication 
protocol described in Section 4.1 as this protocol is a link layer protocol. 


However, the exchange of Commands and Responses is a higher communication layer and 
happens between two entities capable of constructing and extracting the Commands and 
Responses. 


The entity extracting the Commands and constructing the Responses is always part of the Type 3 
Tag. The entity constructing the Commands and extracting the Responses may be part of the NFC 
Forum Device, but might also be part of a device connected via another network to the NFC 
Forum Device. In this case, the NFC Forum Device forwards Command Packet Data it received 
from an entity via another network to the Type 3 Tag by encapsulating the Packet Data using the 
frame format described in [DIGITAL]. 


In a similar way, Response Packet Data received from the Type 3 Tag must be sent to the 
receiving entity by using the protocols of the other network. In this case, the NFC Forum Device 
does not need to interpret the data sent to and received from the Type 3 Tag. 


NOTE Application developers can offer a low-level interface to send and receive arbitrary 
data to a Type 3 Tag. Such a low-level interface enables a number of applications 
that require a remote entity to communicate with a Type 3 Tag. 
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5 Command Set 


This section describes the Command set of a Type 3 Tag, which consists of the Polling, Check, 
and Update Commands. Additionally, an informative state diagram of the Type 3 Tag is 
provided. 


5.1 State Diagram (Informative) 
This section shows the state diagram of a Type 3 Tag. This section is informative only. 


A Type 3 Tag has only one state called “Mode 0”. In this state, the Polling Command, Check 
Command, and Update Command can be received. None of these Commands change the state of 
the Type 3 Tag. 


Polling 
Check 
Update 


Figure 2: Type 3 Tag State Diagram 


5.2 Command and Response Format 


[RQ_T3T_CRF_001] An NFC Forum Device SHALL format Type 3 Tag Commands as 
specified in Table 3: 


Table 3: Generic Data Format for T3T Commands 


Byte 1 Byte 2..X 


Command Code Command Parameters 


[RQ_T3T_CRF_002] An NFC Forum Device SHALL interpret Type 3 Tag Responses as 
specified in Table 4: 
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Table 4: Generic Data Format for T3T Responses 


Byte 1 Byte 2..X 


Response Code Response Parameters 


5.3 Polling Command 


The communication between the NFC Forum Device and a Type 3 Tag begins with the Polling 
Command issued by the NFC Forum Device. The Polling Command is used to detect the Type 3 
Tags in the field. It is also used for initialization and anti-collision. 


[RQ_T3T_CSE_001] The Polling Command is fully specified in [DIGITAL] under the name 
of SENSF_REQ/RES and the corresponding requirements SHALL apply. 


NOTE This specification uses the term IDm instead of NFCID2 defined in [DIGITAL] (see 
Section 2.3.1.1 for information about the IDm). 


5.4 Check Command 


The Check Command is used to read user data from the memory of a Type 3 Tag. 


5.4.1 Command 
[RQ_T3T_CSE_002] The Command Code of the Check Command SHALL be 06h. 


[RO TaT CSE 003] The Check Command SHALL include all data elements in Table 5 and in 
the given order as Command Parameters: 


Table 5: Check Command Parameters 


Data Elements Length | Value | Comments 
in Bytes 


Manufacture ID (IDm) 8 


Number of Services 1 n It depends on the implementation of 
the Type 3 Tag how many Services 
can be read simultaneously. 


Service Code List 2n Each Service Code is specified in 
Little Endian format. 


Number of Blocks 1 m It depends on the implementation of 
the Type 3 Tag how many blocks 
can be read simultaneously. 


Block List 2m - 3m See Section 5.6. 


[RO T3T CSE 004] The Manufacture ID (IDm) SHALL be set to the value included in the 
Polling Response of the targeted Type 3 Tag. 


[RO TaT CSE 005] The Block List SHALL be formatted as defined in Section 5.6. 


[RO T3T. CSE 006] The NFC Forum Device SHALL support values for the Number of 
Services from 1 to 15. 
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[RQ_T3T_CSE_007] Every Service Code List Order value in the Block List Element SHALL 
be smaller than Number of Services. The Maximum number of Service Code List Order is (n-1). 
The order number starts from 0 and is always smaller than Number of Services (n). 


[RQ_T3T_CSE_008] The NFC Forum Device SHALL support values for the Number of 
Blocks from 1 to 15. 


All Services that are specified by the Service Code List Order in Block List Element SHOULD 
exist on the Type 3 Tag. 


Each Service Code value SHOULD be unique inside the Service Code List. 


The Block Number that is set in each Block List Element SHOULD be smaller than the Number 
of Blocks that is defined for the corresponding Service in the Service Definition Information. The 
“Maximum number of Block” value is (m-1) because it starts from 0. This number is always 
smaller than Number of Blocks (m). 


There MAY be Service Codes in Service Code List that are NOT referred to by any of the Block 
List Elements in the Block List. 
5.4.2 Response 


[RQ_T3T_CSE_009] The NFC Forum Device SHALL interpret Responses with the Response 
code of 07h as Check Responses. 


[RQ_T3T_CSE_010] The NFC Forum Device SHALL interpret Check Response Parameters 
to be formatted as defined in Table 6: 


Table 6: Check Response Parameters 


Data Elements Length Value Comments 
in Bytes 

Manufacture ID 8 

(IDm) 

Status Flag1 1 OOh: Success 


Others: Failure 
See Section 5.7 


Status Flag2 1 See Section 5.7 

Number of Blocks 1 m This value is the same as 
Number of Blocks in the Check 
Command. 
(if Status Flag1 = 00h) 

Block Data 16m (if Status Flag1 = 00h) 


[RQ_T3T_CSE_011] The NFC Forum Device SHALL check that the IDm in the Response is 
the same as the one sent in the Check Command. 


[RQ_T3T_CSE_012] The values of Status Flag1 and Status Flag2 SHALL be interpreted 
according to the definition given in Section 5.7. 


The following data is included in the Response if the Status Flag) is equal to OOh: 


e The Number of Blocks is the same value as in the Check Command. 
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e Block Data is the data read from the memory blocks specified in the Check Command. The 
order of Block Data is the same as the order of the Block List Elements in the Block List of 
the Check Command. 


Example: 
Check Command: 
Cmd. No. of Service No. of e 
Code om Services | Code List| Blocks Block List 
06h 1 OOOBh 3 Service Code List | Service Code List | Service Code List 
Order: 0 Order: 0 Order: 0 
Block Number: Block Number: Block Number: 
05h 06h OFh 
Check Response: 
Resp. Status | Status No. of 
Code IDm Flag1 | Flag2 Blocks Blok Data 
07h 0 0 3 Service OOOBh, Service OOOBh, Service OOOBh, 
Block 05h data Block 06h data Block OFh data 


Figure 3: Example of Check Command / Response 


[RQ_T3T_CSE_013] The NFC Forum Device SHALL apply the Timing Requirements defined 
in [DIGITAL] for the Type 3 Tag Platform CHECK Command. 


5.5 Update Command 


The Update Command is used to write user data to the memory blocks of a Type 3 Tag. 


5.5.1 Command 
[RQ_T3T_CSE_014] The Command Code of the Update Command SHALL be 08h. 


[RQ_T3T_CSE_015] The Update Command SHALL include all data elements of Table 7and 
in the given order as Command Parameters: 
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Table 7: Update Command Parameters 


Data Elements Length Value Comments 
in Bytes 


Manufacture ID (IDm) 8 


Number of Services 1 n It depends on the implementation 
of the Type 3 Tag how many 
Services can be written 
simultaneously. 


Service Code List 2n Each Service Code is specified in 
little endian format. 


Number of Blocks 1 m It depends on the implementation 
of the Type 3 Tag how many 
blocks can be written 
simultaneously. 


Block List 2m - 3m See Section 5.6. 
Block Data 16m 


[RO T3T CSE 016] The Manufacture ID (IDm) SHALL be set to the value included in the 
Polling Response of the targeted Type 3 Tag. 


[RO T3T CSE 017] The NFC Forum Device SHALL support values for the Number of 
Services from 1 to 12. 


[RO T3T. GSF. 018] Every Service Code List Order value in Block List Element SHALL be 
smaller than Number of Services. The maximum number of Service Code List Order is (n-1). The 
order number starts from 0 and is always smaller than Number of Services (n). 


All Services that are specified by the Service Code List Order in the Block List Element 
SHOULD exist in the Type 3 Tag memory. 


[RO T3T. CSFE 019] The NFC Forum Device SHALL support values for the Number of 
Blocks from 1 to 13. 


Each Service Code value SHOULD be unique inside the Service Code List. 


The Block Number that is set in each Block List Element SHOULD be smaller than the Number 
of Blocks that is defined for the corresponding Service in the Service Definition Information. The 
“Maximum number of Block” value is (m-1) because it starts from 0. This number is always 
smaller than Number of Blocks (m). 


There MAY be Service Codes in Service Code List that are NOT referred to by any of the Block 
List Elements in the Block List. 


5.5.2 Response 


[RO T3T. CSE 020] The NFC Forum Device SHALL interpret Responses with the Response 
code of 09h as Update Responses. 


[RQ_T3T_CSE_021] The NFC Forum Device SHALL interpret Update Response Parameters 
to be formatted as defined in Table 8: 
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Table 8: Update Response Parameters 


Data Elements Length Value Comments 
in Bytes 


Manufacture ID (IDm) 8 


Status Flag1 1 OOh: Success / 
Others: Failure 
See Section 5.7 


Status Flag2 1 See Section 5.7 


[RQ_T3T_CSE_022] The NFC Forum Device SHALL check that the IDm in the Response is 
the same as the one sent in the Update Command. 


[RQ_T3T_CSE_023] The values of Status Flag1 and Status Flag2 SHALL be interpreted 
according to the definition given in Section 5.7. 


[RQ_T3T_CSE_024] The NFC Forum Device SHALL apply the Timing Requirements defined 
in [DIGITAL] for the Type 3 Tag Platform UPDATE Command . 


5.6 Block List 


5.6.1 Block List Format 
The Block List allows multiple Blocks to be specified in one Command. 


[RO TaT CSE 025] The Block List SHALL consist of one or more Block List Elements. 
Each Block List Element indicates a Block Number within the Service specified by its position in 
the Service Code List Order. 


Figure 4 and Figure 5 show the two possible structures for Block List Elements: 


Byte 0 Byte 1 
a "Se 


Service Code 
Len List Order Block number 


b7 Ire b5 b4 | b3 b2 | b1 | bO | b7 | b6 | b5 | b4 | b3 | b2 | b1 | bo 


Access mode 


Figure 4: Two Bytes Block List Element 
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Byte 0 Byte 1 Byte 2 
6 GEES 


Service 
L Code Block number 


en 
EE EE 
b7|b6|b5ib4/b3|b2|b1 bO b7 b6! b5/b4|b3}b2)b1)b0)b7|b6)b5|b4|b3}b2|b1)/bo 


Access mode 


Figure 5: Three Bytes Block List Element 


[RQ_T3T_CSE_026] Block List Elements SHALL be either in a 2 byte or 3 byte format. 
Which format is used SHALL be specified by the Length bit, which is the MSB of the first byte 
of each Block List Element. The Length bit SHALL be set to 1b to indicate a 2 byte Block List 
Element. The Length bit SHALL be set to 0b to indicate a 3 byte Block List Element. 


[RQ_T3T_CSE_027] Bits 6, 5, and 4 of the first byte of each Block List Element are named 
Access Mode and SHALL be set to 000b. 


[RQ_T3T_CSE_028] Bits 3, 2, 1, and 0 of the first byte of each Block List Element are named 
Service Code List Order and indicate the Service the block referenced in the Block List Element 
belongs to. The Service Code List Order SHALL contain the position of the corresponding 
Service in the Service Code List of the Check or Update Commands. The first Service in the 
Service Code List has the number OOOOb. 


[RQ_T3T_CSE_029] When there is a 2 byte Block List Element, the 2nd byte SHALL contain 
the Block Number. 


[RQ_T3T_CSE_030] When there is a 3 byte Block List Element, the 2nd and 3rd bytes 
SHALL contain the Block Number in Little Endian format. 


5.7 Status Flag 


This section defines the allowed values of the Status Flag that indicate the Type 3 Tag's error 
conditions in a Check- or Update Response. 


The status is described using Status Flag1 (1 byte for indicating the error status and erroneous 
block) and Status Flag2 (1 byte for indicating more details of error information provided by 
Status Flag1). 

5.7.1 Status Flag1 

Status Flag1 is set to OOh if the Command execution was successful. 


If there is an error, a value other than OOh is set. 


5.7.2 Status Flag2 
Status Flag2 is set to OOh if the Command execution was successful. 


Values 70h and 71h indicate hardware errors of the Type 3 Tag (see Table 9). Any other values 
indicate processing errors. 


Type 3 Tag Operation Specification Page 16 


Table 9: Error Code List 


Command Set 


Type 3 Tag Operation Specification 


Error name Explanation Code 
Memory Error Cannot write to memory. 70 
Excessive Writes Memory has been written more than the maximum 71 
number of times. (This value depends on the 
hardware). 
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6 NDEF Detection and Access 


This section describes how the NFC Forum Device can store and access NDEF records on a 
Type 3 Tag using the Commands described in Section 5. 


The procedures described in this section only apply when storing NDEF on a Type 3 Tag. They 
do not describe how to use the Commands described in Section 5 for other use cases. 


NFC Forum Device 


NFC Forum Applications 


NDEF Data 


ys 
Type 3 Tag Commands 


212 or 424 kbps Passive Mode 


Figure 6: Mapping of NDEF to a Type 3 Tag 
6.1 NDEF Management Data 


6.1.1 System Code 

[RQ_T3T_NDA_001] The System Code 12FCh SHALL be used for NDEF-enabled Type 3 
Tags. 

6.1.2 Attribute Information Block 


[RQ_T3T_NDA_002] The NDEF data SHALL be stored on the Type 3 Tag using the memory 
blocks assigned to the Service with Service code OOOBh. 


[RO T3T NDA 003] The Attribute Information Block SHALL be the first block of this 
Service (see Figure 7). The data length is 16 bytes. 
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The first block is used for 


Attribute Information — User Block No.00: Attribute Info. 


ser Block No.01: NDEF data 


ser Block No.02: NDEF data 


Nbc: Number of blocks 


containing NDEF data 
Nmaxb: Number of 


ser Block No. Nbc: NDEF data blocks available for 
NDEF data 
ser Block No. Nbc+1 


User Block No. Nmaxb 


Figure 7: Data Blocks in Service 


Figure 8 shows the structure of the Attribute Information Block: 


User Block No.00 


Byte | Byte | Byte | Byte | Byte | Byte | Byte | Byte | Byte | Byte | Byte | Byte | Byte | Byte | Byte | Byte 
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 
Ver Nbr | Nbw Nmaxb unused | unused | unused | unused | WriteF SC Ln Checksum 


Figure 8: Attribute Information Format 


[RQ_T3T_NDA_004] Byte 0 SHALL be the NDEF Mapping version. The version that 
corresponds to this specification is 1.0. The most significant nibble (the 4 most significant bits) 
SHALL indicate the major version number, and the least significant nibble (the 4 least significant 
bits) SHALL indicate the minor version number. 


[RQ_T3T_NDA_005] The NFC Forum Device SHALL NOT change the value of the NDEF 
Mapping version field. 


[RQ_T3T_NDA_006] Byte 1 SHALL be Nbr, which indicates the number of blocks that can be 
read using one Check Command. 


[RQ_T3T_NDA_007] The NFC Forum Device SHALL NOT change the value of the Nbr field. 


[RQ_T3T_NDA_008] Byte 2 SHALL be Nbw, which indicates the number of blocks that can 
be written using one Update Command. 


[RQ_T3T_NDA_009] The NFC Forum Device SHALL NOT change the value of the Nbw 
field. 


[RQ_T3T_NDA_010] Byte 3 and Byte 4 SHALL be Nmaxb, which indicates the maximum 
number of Blocks available for NDEF data. Byte 3 SHALL be the upper byte, and Byte 4 
SHALL be the lower byte of the maximum number of Blocks. 


[RQ_T3T_NDA_011] The NFC Forum Device SHALL NOT change the value of the Nmaxb 
field. 


[RQ_T3T_NDA_012] Byte 5 to Byte 8 SHALL be 00h and SHALL NOT be changed by the 
NEC Forum Device. 


Type 3 Tag Operation Specification Page 19 


NDEF Detection and Access 


[RQ_T3T_NDA_013] Byte 9 SHALL be WriteFlag. Allowed values for WriteFlag SHALL be: 
e 00h: OFF (Writing data finished) 
e OFh: ON (Writing data in progress) 


The NFC Forum Device SHOULD set this flag to ON before writing to the Type 3 Tag, and set it 
back to OFF after writing. When reading NDEF data from the Type 3 Tag, even if this flag is set 
to ON, the NDEF data on the Type 3 Tag MAY be valid. 


[RQ_T3T_NDA_014] Byte 10 SHALL be RWflag. Allowed values for RWFlag SHALL be: 
e O0Oh: Access Attribute: Read only. 
e Oth: Access Attribute: Read/Write available. 


[RQ_T3T_NDA_015] The NFC Forum Device SHALL NOT try to write to a Type 3 Tag with 
this flag set to OOh, even if writing would be technically possible. Read-only Type 3 Tags always 
have this value set to 00h. 


[RQ_T3T_NDA_016] The NFC Forum Device SHALL NOT change the value of the RWflag. 


[RQ_T3T_NDA_017] Byte 11 to Byte 13 SHALL be Ln, which is the actual size of the stored 
NDEF data in bytes. Byte 11 SHALL be the upper byte, Byte 12 SHALL be the middle byte, and 
Byte 13 SHALL be the lower byte. The number of blocks containing NDEF data (Nbc) can be 


calculated by the formula Nbc = [Ln / 16]. 
[RQ_T3T_NDA_018] The NFC Forum Device SHALL update the Ln field with a correct value 


each time NDEF data has been written. 


[RQ_T3T_NDA_019] Byte 14 and Byte 15 SHALL be a checksum calculated using the 
formula: 


Checksum = Byte 0 + Byte1+---+ Byte13 


Byte 14 SHALL be the upper byte of the checksum, and Byte 15 SHALL be the lower byte of the 
checksum. 


[RQ_T3T_NDA_020] The NFC Forum Device SHALL update the checksum with a correct 
value every time any of the values of Bytes 0 to 13 are changed. 


6.1.3 Versioning 


Byte 0 of the Attribute Information Block contains the version of the applied mapping document 
to the NFC Forum Type 3 Tag. The mapping document version SHALL be indicated with two 
numbers: major version number and minor version number. 


The handling of the different mapping document version numbers applied to the Type 3 Tag 
(called T3VNo) and the one implemented in the NFC Forum Device (called NFCDevVNo) is 
explained in the four cases in Table 10. 
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Table 10: Handling of the Mapping Document Version Numbers 


No Version Number Case Handling 
1 Major NFCDevVNo is equal to | [RQ_T3T_NDA_021] The NFC Forum 
major T3VNo, and Device SHALL access the Type 3 Tag 
minor NFCDevVNo is bigger and SHALL use all features of the applied 
than or equal to minor T3Vno mapping document to this Type 3 Tag. 
2 If major NFCDevVNo is equal [RQ_T3T_NDA_022] Possibly not all 
to major T3VNo, and features of the Type 3 Tag can be 
minor NFCDevVNo is lower accessed. The NFC Forum Device 
than minor T3Vno SHALL use all its features and SHALL 
access this Type 3 Tag. 
3 If major NFCDevVNo is smaller | [RQ_T3T_NDA_023] Incompatible 
than major T3Vno data format. The NFC Forum Device 
cannot understand the Type 3 Tag data. 
The NFC Forum Device SHALL reject 
this Type 3 Tag. 
4 If major NFCDevVNo is bigger | [RQ_T3T_NDA_024] The NFC Forum 
than major T3Vno Device might implement the support for 
previous versions of this specification in 
addition to its main version. In case the 
NFC Forum Device supports the previous 
version, it SHALL access the Type 3 Tag. 
On the contrary, in case the NFC Forum 
Device does not support the previous 
version, it SHALL reject the Type 3 Tag. 


Future versions of this specification have to define the allowed actions to an NFC Forum Tag 
with a version number lower than the version number of the NFC Forum Device (e.g., whether it 
is allowed to upgrade the NFC Forum Tag to the new version). 


6.2 NDEF Storage 


[RQ_T3T_NDA_025] The NDEF data SHALL be stored on the Type 3 Tag using the memory 
blocks assigned to the Service with Service Code OOOBh. 


If the Type 3 Tag allows write access to the NDEF data, Service 0009h is available as an Overlap 


Service. 


[RQ_T3T_NDA_026] The NFC Forum Device SHALL use Service Code 0009h to write NDEF 


data. 


Type 3 Tag Operation Specification 


Table 11: NDEF Services 


Usage Service setup 
NDEF is Read-Only Service Code OOOBh is available. 
NDEF is Read/Writeable Service Code 0009h and Service Code OOOBh are 


available as Overlap Services. 
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The first byte of Block Number 1 of Service OOOBh contains the first byte of NDEF data. If the 
NDEF data is larger than 16 bytes, the 17th byte of NDEF data is stored in the first byte of User 
Block Number 2. The whole NDEF data is stored on the Type 3 Tag in this way. 


[RQ_T3T_NDA_027] When the NFC Forum Device reads NDEF data, it SHALL ignore the 
padding if the NDEF data does not use all bytes of the last block. 


[RQ_T3T_NDA_028] When the NFC Forum Device writes NDEF data to the Type 3 Tag, 
padding data MAY be added if the data length of the NDEF data is not a multiple of 16. Padding 
byte SHALL be (00h). 


User Block No. Nbc 


— — 
Padding Data 


Figure 9: Relation between NDEF Data and Storage Blocks 


6.3 Life Cycle 


This section describes the lifecycle of an NDEF-enabled Type 3 Tag, which may be in different 
states. Every state has its own valid operations. 


For all states, the Type 3 Tag is considered to be initialized properly for NDEF data (System 
Code is 12FCh, the Service OOOBh exists, and the attribute information data is initialized 
properly). 

The NDEF-enabled Type 3 Tag shall be delivered in one of the following states: INITIALIZED, 
READ/WRITE, or READ-ONLY. 

The NFC Forum Device shall interpret the Type 3 Tag to be in one of the following states: 

e INITIALIZED 


The Type 3 Tag can be used to write NDEF data. Service 0009h exists as Overlap Service. 
The NFC Forum Device can write NDEF data using this Service Code. In this state, the Type 
3 Tag does not contain any valid NDEF message content (Ln byte in the Attribute 
Information Block is Oh). 


e READ/WRITE 


The Type 3 Tag is considered to contain a valid NDEF message and be available for 
read/write access. Service 0009h exists as Overlap Service. The NFC Forum Device can read 
and write NDEF data using this Service Code. 
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This state provides the ability to read the NDEF message and also to modify it (i.e, 
completely overwrite the existing NDEF message with a new NDEF message). 


e READ ONLY 


The Type 3 Tag is considered to contain a valid NDEF message and be available for read- 
only access. The NFC Forum Device can read NDEF data using Service Code OOOBh. The 
NDEF message cannot be deleted or overwritten with anew NDEF message. Service 0009h 
does not exist. 


Update 


READ/WRITE 


Update 


READ ONLY 


Figure 10: Life Cycle States 
6.4 Command Sequence Description 


6.4.1 NDEF Detection 
NDEF data in the Type 3 Tag MAY be detected by the NFC Forum Device as follows: 
STEP 1: 


The first step to detect NDEF-enabled Type 3 Tags consists of the detection of Type 3 Tags in the 
RF field having a System Code of 12FCh. 


The NFC Forum Device sends a Polling Command with System Code 12FCh. NDEF-enabled 
Type 3 Tags respond to the Polling Command by sending a Polling Response including IDm and 
PMm. 


If there is at least one Type 3 Tag with System Code 12FCh in the field, go to STEP 2; otherwise, 
repeat STEP 1. 
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Polling Command 


Tags with 
System Code 
12FCh? 


Sequence for proprietary 
FeliCa application 


Sequence for reading or 
writing NDEF data 


Figure 11: General Sequence for Detecting NDEF Data 


STEP 2: 


[RQ_T3T_NDA_029] If there is more than one NDEF-enabled Type 3 Tag in the field, the 
NFC Forum Device SHALL select one of them for this step. The NFC Forum Device MAY 
perform step 2 sequentially for each NDEF-enabled Type 3 Tag. 


[RQ_T3T_NDA_030] The NFC Forum Device SHALL read the Attribute Information data 
using the Check Command. For the Check Command, the NFC Forum Device SHALL use the 
same IDm that it received in the Polling Response from the Type 3 Tag. 


The value of the Number of Services SHOULD be equal to 1. 


[RQ_T3T_NDA_031] The Attribute Information data contains a checksum to confirm that the 
Attribution Information data is valid. The NFC Forum Device SHALL validate the checksum. 


[RQ_T3T_NDA_032] The NFC Forum Device SHALL check if it supports the NDEF mapping 
version number based on the rules given in Section 6.1.3. 


If the checksum is correct and the NFC Forum Device supports the NDEF mapping version, the 
NFC Forum Device MAY proceed with: 


e The read NDEF message phase, or 
e The write NDEF message phase 


[RQ_T3T_NDA_033] Ifthe checksum is not correct or the NFC Forum Device does not 
support the NDEF mapping version, the NFC Forum Device SHALL NOT read or write NDEF 
data to this Type 3 Tag. 


If the Attribute Information data is valid, the NFC Forum Device knows the parameters Nbr, 
Nbw, Nmaxb, RWflag, and Ln. 


If the value of Ln is greater than 0, the Type 3 Tag contains NDEF data. 


6.4.2 Read NDEF Message 


The purpose of this phase is to read the data blocks containing NDEF data in order to assemble 
the NDEF data structure stored on the Type 3 Tag. 


[RQ_T3T_NDA_034] For all Commands, the NFC Forum Device SHALL use the same Um 
that was used during the NDEF detection phase for the selected Type 3 Tag. 
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For all Commands used in this phase, the value of the Number of Services SHOULD be equal 
to 1. 


For reading NDEF data, the NFC Forum Device SHOULD use a minimum number of Check 
Commands by maximizing the Number of Blocks to read per Command. 


[RQ_T3T_NDA_035] The NFC Forum Device SHALL read the blocks from User Block No. 
01 until User Block No. Nbc. Nbc SHALL be calculated as explained in Section 6.1.2. 


Polling Command 


STEP 1 
Tags with Proprietary 
System Code A 
12Fch? Application 
m 
Read Attribute S F NDEF 
Information Block 3 etection 
D phase 
< 
3 
Checksum and version D 
check z 
STEP 2 z 
Si 
> 
OD 
Checksum S 
and version D 
correct? 
WriteFlag check 
F Read NDEF 
2 E message 
E j phase 


Yes 


NDEF data read 


Figure 12: General Seguence for Reading NDEF Data 


6.4.3 Write NDEF Message 


The purpose of this phase is to write NDEF data to a Type 3 Tag. Any existing NDEF data on the 
Type 3 Tag will be overwritten. 
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[RQ_T3T_NDA_036] For all Commands, the NFC Forum Device SHALL use the same [Dm 
that was used during the NDEF detection phase for the selected Type 3 Tag. 


For all Commands used in this phase, the value of the Number of Services SHOULD be equal 
to 1. 


For writing NDEF data, the NFC Forum Device SHOULD use a minimum number of Update 
Commands by maximizing the Number of Blocks to write per Command. 


[RQ_T3T_NDA_037] The NFC Forum Device SHALL check the RWFlag and only attempt to 
write if its value is 01h. 


Before writing NDEF data, the NFC Forum Device MAY check if the NDEF data size is smaller 
than the maximum memory size for NDEF data available on the Type 3 Tag. 


[RQ_T3T_NDA_038] In this case, the NFC Forum Device SHALL calculate the maximum 
memory size for NDEF by multiplying Nmaxb times 16. 


[RQ_T3T_NDA_039] Before writing NDEF data, the NFC Forum Device SHOULD update the 
Attribute Information with the WriteFlag set to ON. 


[RQ_T3T_NDA_040] The NFC Forum Device SHALL start writing the blocks from User 
Block No. 01 until User Block No. Nbc. The number of blocks to use for NDEF data (Nbc) 
SHALL satisfy Nbc<= Nmaxb. 


[RQ_T3T_NDA_041] After writing the NDEF data, the NFC Forum Device SHALL write 
updated Attribute Information data to User Block No. 00 using the Update Command. 


[RQ_T3T_NDA_042] The Length information within the Attribute Information SHALL be 
changed according to the amount of NDEF data written. 


[RQ_T3T_NDA_043] The WriteFlag SHALL be set to OFF. 
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Polling Command 


Tags with d 


STEP 1 
Proprietary 
System Code ET 
12Fch? Application 
m 
S 
3 
< NDEF 
Read Attribute S d l 
Information Block H etection 
= phase 
O 
z 
Checksum and version g 
check = 
STEP 2 S 
LO 
D 
Checksum 
and version 
correct? 
Yes 
Set WriteFlag to ON 
' Write NDEF 
NDEF data write message 
phase 


Write Attribute 
Information Block 


(WriteFlag set to OFF) 


Figure 13: General Sequence for Writing NDEF Data 


6.4.4 State Changes 


A state change from “INITIALIZED” to “READ/WRITE” can be performed by writing a valid 
NDEF message to the Type 3 Tag as described in Section 6.4.3. 


A state change from “READ/WRITE” to “INITIALIZED” can be performed by updating the 
attribute information block with an Ln value of 0. 
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A. Typical Activation Sequence 


This appendix is informative, outlining the typical activation sequence from the point of view of a 
standalone NFC Forum Device implementation. 


The communication between the NFC Forum Device and the Type 3 Tag is initiated as follows: 


1. The NFC Forum Device switches on the RF field. The NFC Forum Device sends a Polling 
Command. The NFC Forum Device should wait for at least 20 milliseconds after switching 
the RF field on before sending a Polling Command. 


2. The NFC Forum Device waits to receive Polling Responses from the Type 3 Tags in the field. 
If the NFC Forum Device fails to receive a Polling Response, then the NFC Forum Device 
may send a Polling Command again. 


3. Each Polling Response contains the IDm information of the sending Type 3 Tag, which can 
be used by the NFC Forum Device as part of the Check and Update Commands to further 
communicate with the Type 3 Tag. The NFC Forum Device may communicate with multiple 
Type 3 Tags using their respective IDm values. 
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B. Revision History 


The following table outlines the revision history of Type 3 Tag Operation Specification. 


Table 12: Revision History 


Document Name Revision and Status Change Notice Supersedes 
Release Date 

Type 3 Tag Operation Version 1.0, Final None 

Specification July 2007 

Type 3 Tag Operation Version 1.1, Final Alignment with Version 1.0, 

Specification June 2011 Digital and Activity July 2007 


specification, fixed 
errata, editorial 
improvements; 
editorial updates for 
Figures 2 and 8 
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